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Abstract 

In this paper I introduce a mechanism to derive program transforma¬ 
tions from order-preserving transformations of vector types. The purpose 
of this work is to allow automatic generation of correct-by-construction 
instances of programs in a streaming data processing paradigm suitable 
for FPGA processing. We show that for it is possible to automatically 
derive instances for programs based on combinations of opaque element¬ 
processing functions combined using foldl and map, purely from the type 
transformations. 


1 Introduction 

In this discussion paper I want to introduce a set of type transformations 
on vector types. In this work we will use a simple form of dependent types 
|Bove and Dybjer, 2009| , but the concept can be generalised to transformations 
on other types, including session types [Honda et ah, 2008| . The overall idea 
is to introduce the transformations and then explore the effect of transforming 
the types in a program on the program itself, i.e. what are the required cor¬ 
responding functions that will transform the types of the computations while 
preserving the results of the computations. 

The purpose of this work is to allow automatic generation of correct-by- 
construction instances of programs in a streaming data processing paradigm 
suitable for data processing using FPGAs (Field Programmable Gate Arrays, 
jVanderbauwhede and Benkrid, 2013j ). Using an optimisation technique such 
as simulated annealing [Aarts and Korst, 1988| and a cost model for the FPGA 
implementation, the best instance can be automatically selected. 

2 Preliminaries 

2.1 Type Variables 

a is a type variable representing a nullary type constructor. We will call this 
kind of type variable atomic. 
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b,c are general type variables. We call the set of these type variables B 

k,l,m,n are non-zero natural numbers, i.e. k^m,n G N>o. We will call these 
sizes. 

p,q are (unary) type constructor variables, i.e. types that apply to other types 
and can depend on non-zero natural numbers, e.g. pna or pkqqb. 
Note that we use unary (i.e. one type and one size), right-associative 
type constructors purely to simplify the discussion, not as a fundamental 
limitation. The crucial point is however that these are dependent types. 

F,G,H are general functions operating on types (we could call them type trans¬ 
formers). We assume the functions take a single type as argument and are 
right associative. Consequently, we can write G (F a) a,s G F a 

S,M,R and I are specific functions operating on types, to de defined later. 

2.2 Notations and Definitions 

total size The total size of a type is the product of all sizes: 

A/'(pi ni p 2 n 2 ...pi...pk nk a) = HLi nt 

type transformation A type transformation is the application of a function 
from one type to another to a type, i.e. F b = c 

i,j are used as subscripts to distinguish between type variables of the same 
class, so that we can write pi p 2 ...pi...pk ci 


3 Restrictions on Type Transformations 

Given a type expression of the form pi ni p 2 n 2 ...pi...pk nk a, the type transfor¬ 
mations we want to consider must obey following restrictions: 

1. The transformations do not remove any atomic type variables or introduce 
fresh atomic type variables. It follows that atomic type variables cannot 
be modified either. 

2. The transformations can only remove or add one or more outer type con¬ 
structors. 

3. The type transformations can transform the sizes, but the total size of the 
type is an invariant. 

Although the types and transformations are more general, our focus is on trans¬ 
formations of types describing ordered sets. The above restrictions intend to 
reflect that the type transformations should not alter the number or nature of 
the elements of the set, but only the way the set is partitioned. 
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4 Vector Types 

For general types pi it may be hard to prove that the above rules do not alter 
the number or nature of the elements of the set, but only the way the set 
is partitioned. However, if we assume a single type representing a vector, then 
what these restrictions say is that a vector can only be reshaped but not modified 
in terms of its type or size. This is of course not a sufficient condition to 
guarantee that the type transformations will not change the computations, but 
it is a necessary one. 

We introduce the vector type v kb where k is a non-zero positive integer and 
b is an arbitrary type. This the type representing a vector of length k containing 
values of type b. Specifically we define 

b = vOb 

Given an atomic type a, we can generate the set of all vector types V (a) for 
a as follows: 


\a£V{a) 

€ V{a),ykinN>o\vkb€V{a) 

For convenience, we introduce the following notation: 
vkb "=■ [b]{k) 

And the shorthand: 

[...[[&](fcl)](fc2)...](fc„) ”= [b]{k,){k2)...{kn) 


5 Transformations on Vector Types 

For the rest of the paper we consider a specific case of types and type transfor¬ 
mations: transformations on vector types. I posit three fundamental transfor¬ 
mations, each with a corresponding inverse: 

• converting a type to a singleton vector type 

• applying a type transformation to the type variable of a vector type {map¬ 
ping) 

• reshaping a vector type, i.e. modifying the sizes in a vector type such that 
the total size is remains invariant 

We can formalise each of these transformations: 

5.1 Singleton vector type 

The purpose of this operation is to change the dimensionality of a vector. 

Sb = [&](!} 

The inverse operation (reducing dimensionality) is defined trivially as 
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s-^mi) = b 

So that 
S-'^Sb = b 

55-M&](l) = [&](1) 

Repeated application of S leads to higher-dimensional singleton vectors: 
55 & = [[ 6 ]( 1 )]( 1 ) 

We introduce a convenient notation 
S>^b= [6](1)'= 

5.2 Mapping 

Mapping applies a transformation to the type argument of a vector type. 

This operation is independent of the size, so I have omitted it: 

MF[b] = [Fb] 

Note that the inverse operation is the application of the inverse of F, not of 
M: 

MF-^[Fb] = [b] 

Although of course we can define purely notationally 
M-^F = MF-^ 

Repeated application of M has two cases. The first case is applying different 
transformations to a 1-D vector 
(MF) (MG) [b] = [FGb] 

We can rewrite the Ihs as 
(M F) (M G) [b] =M{FG) [b] 

The second case is applying a single transformation to a multi-dimensional 
vector 

M (M F) [[6]] = [MF [&]] = [[F b]] 

We can rewrite the Ihs as 
M{MF) [[6]] = M'^F[[b]] 

5.3 Reshaping 

The purpose of this operation is to re-partition a vector. The operation works 
on a 2-D vector. 

i?m [[&](ni)](n2) = [[6](ni.m)](n2/m) 

The condition on m is of course that n/m is a natural number, i.e. n 2 is a 
multiple of m. 

The inverse operation can again be defined notationally: 

Rm,-^ [[b]{ni)]{n 2 ) = [[b]{ni/m)]{n 2 .m) 
and 

R~^ m = Rm~^ 
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5.4 Identity Operation 

We define I b = b for completeness. I contend (but have not formally proven) 
that the set of operations S,M,R,I form a group over V(a). Each of the opera¬ 
tions is associative and can be inverted, and any combination of operations on 
a vector type results in a vector type, i.e. it is closed as well. By adding I, the 
conditions for a group are satisfied. 

In fact, as we shall show below, S,M,R,I form a group over a particular finite 
subset of V(a): 

• define V(a,n) as the subset of V(a) where, for any given vector [a]{ki){k 2 )...{km), 

UT=ik.=n. 

• then S,M,R,I form a group over E(a,n),Va, n 

In the next section, we will give a proof of the closure constraint. 

5.5 Operations on Atomic Types 

We define mapping on or reshaping of an atomic type as identity operations: 

MFa = a 


Rka = a 


5.6 Vector Creation 

For what follows, we will need an invertible operation V to create vector types: 
Vkb= [5](fc) 
with its inverse 
V-^k[b]{k) = b 

In other words, V is equivalent to the vector type constructor but has an 
inverse. We use this operation to formally extract the argument of a vector 
type from the constructor. The dependent variable k is not strictly speaking 
necessary: 

V~^ k(v kb) = b 

However, for any vector type c, V~^kc will result in a type error unless 
c = V kb. 

5.7 Theorem: V(a,n) is closed and complete under S,M,R 

Theorem 1. Any type transformation on any vector type in V(a,N) that ob¬ 
serves the rules from Section\^' 

1. can be expressed as a combination of the operations S, M and R, and 

2. results in a vector type in V(a,N). 
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Proof. 

• The most general expression for a type in our system is and multidimen¬ 
sional vector of type a, where the size in every dimension is different. We 
consider two instances of this type: 


'ri=[a] {ni){n 2 )...{ni)...{nk) 
T 2 = [a]{rni){rn 2 )...{rnj)...{rrii) 


where 


k i 

Y[n, = Y[mj = N 

i=i j=i 

and in general k ^ I and the various rii and rrij values can be different. 

• We aim to show that Ti can be transformed into T 2 through application 
of a combination of the operations 5, M and R. Our approach is to first 
reduce T\ to a one-dimensional vector of size N, and then transform this 
vector into T 2 . 

• First we reduce the expression for Ti to [a]{7V)as follows 

1. First reshape the outer two vectors through application of R: 

R~^ ruk-i Ti 

= [a]{ni){n2)...{ni)...{nk-i){nk) 

= [a]{ni){n 2 )...{n^)...{l){nk-i.nk) 

which can also be written as 


[[[a](ni)(n2)---(ni)...(nfe_2)](l)](nfc_i.nfe) 

2. Then apply S~^ to the type of the outer vector: 

M 5“^ [[[a]{ni){n2)...{ni)...{nfc_2)](l)]{nfc_i.nfe) 

= [S~'^ [[a](ni){n2)...(nj)...{nfc_2)]{l)](nfc_i.nfe) 

= [[a\{ni) (712) ...{rii) ...{nk-2)]{nk-i-nk) 

3. Repeating these steps results in 

[a](ni.n2. Ui . nu) 

which can be written as 

[«](iV) 
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• Then we perform the reverse process to obtain T 2 '. 


1. First increase the dimensionality by calling S on the type of the outer 
vector 

MS[a]{N) = [[a]mN) 

2. Then reshape the outer two vectors using R 

Rrrii [[a](l)](iV) = [[a](mi)](7V/mi) 

3. Repeating these steps results in 


[a]{rni){rn 2 )...{rnj)...{mi) = T 2 


□ 

Corollary 1. An type transformation consisting of a combination of the trans¬ 
formations S,M and R is reversible. 


6 Program Transformations 

In this section we want to explore how transforming a top-level type impacts 
on the program. The context is the FPGA architecture developed for the TyTra 
projecllj, which is similar to the MORA architecture [Chalamalasetti et ah, 2009| , 
and we consider a simple pipeline of computations. Like MORA, and indeed 
most FPGA architectures, TyTra assumes that data is streamed, and we model 
this as a map over a vector. 

I will use the notation ts or t{s) to mean “the type of s”, and denote type- 
transformed functions and variables using a prime, e.g. s’. 

I will use the notation {b} to indicate “b may have to be transformed” during 
the inference process. 


6.1 General Assumption on the Program 

The general assumption is that the program is built entirely out of 

• a set of functions on atomic types fj :: at ^ au 

• the fold operation Hutton, 1999| 

• the cons (.') operation 

• tuple construction (,) 


^http://tytra.org.uk/ 
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However, we immediately note that foldl can be defined in terms of fold and 
the identity function id: 

foldl f V xs = foldr {Xx g (Xa —> g {f ax)))idxsv 
and map in terms of fold and cons: 

map f = foldr (Xv x —>■ (x : v)) 

and the same goes for all basic list operations, so we take those as given. 
Essentially, our purpose is to split the program in computational functions 
and functions which describe the communication. Based on the type transfor¬ 
mations, we aim to derive the transformation of those higher-order functions. 
We start with a few exploratory examples using map and foldl. 

6.2 Increasing dimensionality — map 

We assume a very simple program, we use Haskell syntax [Hudak et ah, 1992] 
augmented with the (N) notation to indicate sizes. 

s :: [a] (N) 
g :: [a] {N) ^ [a] (TV) 
r :: [b] {N) 
f :: a ^ a 
r = gs 
g = mapf 

For completeness: 

map :: (ti —^ 2 ) ^ [H] (n) —)• [^ 2 ] {n) 

We transform the top-level type: 

t'=RkMSts=RkMS[a] {N)= [[a] {k)]{N/k) 

As g is applied to s, this leads to a transformation of g: 
ig'= ts' t? 

We assume that we only explicitly transform each of the arguments of g. 
Then we get: 

9 ' ■■■■ t's ^ [b] (TV) 
g' = rnapf 

We can substitute ti by the actual type of s' in the map inside g’: 
r' = g' s' = mapgi f s' 

mapg! :: {V~^ {N/k)ts’) -t {b} -)• ^ {[&] (N)} 

Clearly, this type can’t work for map because the return type [6] (TV) has a 
different size from tg' ■ So we need to transform that type: 
t2> =Rk MS [b] (TV) = [b (k)] {N/k) 

This means that the signature for the map in g’ becomes 
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mapg! :: {V ^{N/k)ts'^V ^{N/k)t2') ^ tgr ^ t2' 


So that 

g' :: ts' ^ 2 ' 
Consequently 

U' = t{g' s') = t 2 ' 


Rewriting the above in a more systematic way: 

g’ s’ = map f’ s’ 

mapg/ :: (ti —>■ ^2) [ti] —> [^2] 

(.{a} -> {[b]<k>}) -> [ [a] <k>] <N/k> -> {[b<N>} 

i{V~^N/k [[a]<k>]<N/k>} -> {[b]<k>}) -> [ [a] <k>] <N/k> -> {[b<N>} 
([a]<k> -> {[b]<k>}) -> [[a]<k>]<N/k> -> {[b]<N>} 

([a] <k> -> {[b]<k>}) -> [a] <k*m> -> RkMS {[b]<N>} 

([a]<k> -> {[b]<k>}) -> [a]<k*m> -> [b<k>]<N/k> 

( [a] <k> -> {V~^ N/k [b<k>]<N/k>}) -> [a] <k*m> -> [b] <k*m> 

([a]<k> -> b<k>) -> [a]<k*m> -> [b]<k*m> 
f’ :: [a]<k> -> b<k> 

^ r’ :: [b<k>]<N/k> 

In other words, we can infer the return type from the single type transformation. 

What we have so far is 

s' :: [o'] {N') 

g' :: [a'] {N') ^ [b'] {N') 

r' :: [b'] {N') 

f :: a' b' 

r' = g's' 

g' = mapf 


mapg/ 

mapg/ 

mapg/ 

mapg/ 

mapg/ 

mapg/ 


where 

type a' = [a] (k) 
type b' = [b] (k) 

N' = N/k 

What we need now is the transformations between s and s ’ and / and / ’ 
To transform s: 

s' = reshapeTofcs 


where 

reshapeTo :: Int k^k^[a] (n) [[a] (fc)] (n/k) 
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We define the inverse for further use: 

reshapeFrom :: Int fc => fe —^ [a (A:)] (n) —>■ [a] {n.k) 

So the R k M S t(s) type transformation maps directly to reshapeTo k s 

The transformation from / to /’ is even more straightforward, because the 
transformation of the original type raises the dimensionality 

/' = mapf 

In general, the original map is replaced by maps over both dimensions. 
g' = map map f 

and in full, the transformed program becomes 

r = {reshapeFrom k) . {mapmapf) . {reshapeTo k) s 


6.3 Reducing the dimensionality — map 

Assume we have 

s :: [[a] (k)] (m) 

5 :: [[a]{k)]{m)^[[b]{k)]{m) 
g = mapf 
f :: [a] (A) ^ [b] (A) 
r = gs 

And we apply the transformation M S~^ R~^k to s: 

R~^ kt{s) = [[a] {!)] (A.m) 

M S~'^ [[a] (1)] (A.m) = [a] (A.m) 
t{s') = [a] (A.m) 

So we obtain 

s' :: = [a] (A.m) 

As 5 ’ is applied to s we obtain 

g' :: [a] (A.m) ^ {[[b] (A)] (m)} 

Now we use inference on map: 

g’ s’ = map f’ s’ 

(t_l -> t_2) -> [t_l] -> [t_2] 

(a -> {[b]<k>}) -> [a]<k*m> -> {[[b]<k>]<m>} 

(a -> {[b]<k>}) -> [a]<k*m> -> M S~^ R~^ k {[[b]<k>]<m>} 

(a -> {[b]<k>}) -> [a]<k*m> -> [b]<k*m> 

(a -> {V~^ k.m [b]<k*m>}) -> [a] <k*m> -> [b] <k*m> 

(a -> b) -> [a]<k*m> -> [b]<k*m> 

=^> f ’ : : a -> b 
r’ :: [b]<k*m> 


mapg/ 

mapg- 

mapg- 

mapg/ 

mapg/ 
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to express /' as a function of / , we need a toVector k x function 
toVector :: Int fc => /c a — >■ [a] (fc) 

The most intuitive implementation seems to be 
toVector ;: k x = replicate k x 
Similarly, we need fromVector k x (although we don’t really need k) 
fromVector :: Int /c ^ fc —^ [a] (fe) —^ a 
The most intuitive implementation seems to be 
fromVector k (x:_) = x 
With these, we simply say 

f X = fromVectorfc (/ (toVector kx)) 

6.3.1 Correctness condition 

In general, the above transformation does not necessarily preserve the compu¬ 
tation. However, we can see that a sufficient condition to preserves the compu¬ 
tation is that map / ’ = / : 

Lemma 1. Mapping f’ over s’ preserves the computation of mapping f over s 

^ff 

f = map h 
Proof. 

1. Observe that s’ = reshapeFrom k s and we must show that 
r’ = g’ s’ = reshapeFrom k r = reshapeFrom kgs 

2. We show that map f’ s’ = map h s’ 

(a) Mapping/’ to s’: 

r’ = g’ s’ = map /’ s’ 

= If’ xlj’ x2,...J’ xkj’ ylj’ y2,...,f’ yk,...,f’ zlj’ z2,...,f’ zk] 

(b) /’ is identical to h: 
f’ X 

= fromVector k (f (toVector k x)) 

=head (f [xj) 

= head (map h [x]) 

= head [h xj 

= h X 

^f’ = h 
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=> r’ = map f’ s’ = [h xl,h x2,...,h xk,h yl,h y2,...,h yk,...,h zl,h z2,...,h 
zkj 

3. Mapping / to s: 

r = g s = map f s 

= map f [[xl,x2,...,xkl,fyl,y2,...,yk],...,[zl,z2,...,zk]] 

= If fxl,x2,...,xkl,f [yl,y2,...,yk],...,f [zl,z2,...,zk]],...] 

= [map h [xl,x2,...,xk],map h [yl,y2,...,ykj,...,map h [zl,z2,...,zkjj 
= [[h xl,h x2,...,h xk], [h yl,h y2,...,h yk],...,[h zl,h z2,...,h zk]j 

4. Finally, transforming r to r’: 
reshapeFrom k r 

= reshapeFrom k [[h xl,h x2,...,h xk], [h yl,h y2,...,h yk],...,[h zl,h z2,...,h 
zkj] 

= [h xl,h x2,...,h xk,h yl,h y2,...,h yk,...,h zl,h z2,...,h zkj 


□ 


6.4 Preserving the dimensionality — map 

With the same example as above, we apply the transformation RnR~^ k to s: 

R~^ kt{s) = [[a] (1)] (fc.m) 

Rn [[a] (1)] {k.m) = [a {n)] {k.m/n) 
t{s') = [a (n)] {k.mfn) 

So we obtain 

s' :: [a (n)] {k.m/n) 

As g’ is applied to s ’, we obtain 
g' :: [a (n)] {k.m/n) ^ {[b (k)] (m)} 

Again we use inference on map: 

g’ s’ = map f’ s’ 

(t_l -> t_2) -> [t_l] -> [t_2] 

(a<n> -> {[b]<k>}) -> [a<n>]<k*m/n> -> {[[b]<k>]<m>} 

(a<n> -> {[b]<k>}) -> [a] <k*m> -> RnR~^k {[ [b] <k>] <m>} 
(a<n> -> {[b]<k>}) -> [a]<k*m> -> [b<n>]<k*m/n> 

(a -> {V~^ k.m/n [b<n>] <k*m/n>}) -> [a] <k*m> -> [b] <k*m> 
(a<n> -> b<n>) -> [a]<k*m> -> [b]<k*m> 
f’ ;; a<n> -> b<n> 

=> r’ ;; [b<n>]<k*m/n> 

As map is independent of the size of the vector, we have 

f = f 

Consequently, the computation will always be preserved. 


mapg/ 

mapg/ 

mapg/ 

mapg/ 

mapg/ 
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6.5 Increasing dimensionality — fold 

We can easily show that if the operation on f is a fold, then increasing the 
dimensionality results in applying the fold to every dimension. 

Lemma 2. Repeated application of fold to a nested list is equivalent to applying 
fold to the flattened list 

fold (fold f) acc [[xl,x 2 ,...xk],[yl,y 2 ,...yk],...] = fold f acc [xl,x 2 ,...,xk,yl,y 2 ,...,yk,...,zl,z 2 ,...,zk] 
Proof. 

fold (fold f) acc [ [xl,x2,...xk] ,fyl,y2,...y] ,...,[zl,z2,...,zk]] 

= (fold f ... (fold f (fold f acc [xl,x2,...,xkj) fyl,y2,...,ykl) ... fzl,z2,...,zkl) 

= (fold f ...(fold f (f... (f (faccxl) x2) ... xk) fyl,y2,...,ykj) ... [zl,z2,...,zk]) 

= (f ■■■ (f (f ( ■■■ (f (f (f (f ■■■ (f (f acc xl) x2) ... xk) yl) y2) ... yk) ... 

) zl) z2) ... zk) 

= fold f acc fxl,x2,...,xk,yl,y2,...,yk,...,zl,z2,...,zk] 

□ 

Furthermore, as we consider a streaming operations, we only consider the 
left fold (foldl). 

We assume the same program as for map above: 

s :: [a] (n) 
g :: [a] (n) -)> b 
r :: h 

f :: b ^ a ^ b 
acc :: b 
r = gs 

g = fold/acc 
For completeness: 

fold :: (^2 —t ti —^ ^ 2 ) —t t 2 —^ [ti] (to) —^ t 2 

We transform the top-level type: 

t(= R k M S ts = R k M S [a]<n> = [fa]<k>]<n/k> 

So we obtain 

s' :: [a (/c)] (n/k) 

As 5 ’ is applied to s \ we obtain 

g' :: [a (n)] {k.m/n) —>• { 6 } 

Using inference on fold: 

g’ s’ = fold f’ acc s’ 

foldg- :: (t_2 -> t_l -> t_2) -> t_2 -> [t_l]<m> -> t_2 

foldg/ :: (.{b} -> {a}->{b}) -> {b} -> [a] <k><n/k> -> {b} 

foldg/ :: {{b} -> {V~^n/k [a]<k><n/k>} -> {b}) -> [a] <k><n/k> -> {b} 

foldg/ :: (.{b} -> [a] <k> -> {b}) -> [a] <k><n/k> -> {b} 
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At this point, the types are valid, so no further transformation is required 

foldg/ :: (b -> [a]<k> -> b) -> [a]<k><n/k> -> b 
f ’ : : b -> [a] <k> -> b 
^ r’ :: b 
acc ’ : : b 

To transform / into /’: 

/' = foldf 

6.6 Decreasing dimensionality — fold 

We assume the same program as for map above: 

s :: [a (A:)] (m) 
g :: [a (/c)] (m) ^ b 
r :: b 

f :: b ^ a (k) —>■ b 
acc :: b 
r = gs 

g = fold/acc 
For completeness: 

fold :: (^2 —^ ti —y ^2) —t ^2 —t [ti] (to) —y t2 

We transform the top-level type: 

t'^= M S~^ R~^ k tg = M S~^ R~^ k [a]<k><m> = [a]<k.m> 

So we obtain 

s' :: [a] (k.m) 
s' = flattens 

As 5 ’ is applied to s we obtain 
g' :: [a] {k.m) { 6 } 

Using inference on fold: 

g’ s’ = fold f’ acc s’ 

foldg' :: (t_2 -> t_l -> t_2) -> t_2 -> [t_l]<m> -> t_2 

foldg/ :: {{h} -> {[a] <k>}->{b}) -> {b} -> [a] <k*m> -> {b} 

foldg/ :: {{b} -> {V~^ k.m [a]<k.m>} -> {b}) -> [a] <k*m> -> {b} 

foldg/ :: {{b} -> a -> {b}) -> [a] <k*m> -> {b} 

At this point, the types are valid, so no further transformation is required 
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foldg/ : : (b -> a -> b) -> [a]<k*m> -> b 
f ’ ; ; b -> a -> b 
r’ : : b 
acc’ :: b 

To transform / into /’: 

f accx = f acc {toYector k x) 

6.6.1 Correctness condition 

In the case of fold, “preserves the computation” means “produces an identical 
result”, as from the perspective of the type transformation, the type b is opaque. 

In general, folding / ’ over s ’ is not equal to folding / over s. However, a sufficient 
condition for equality is this: 

Lemma 3. Folding f’ over s’ is equal to folding f over s ijf 
f = fold h 

Proof. 

1 . foldl /’ acc s’ = foldl h acc s’ 

foldl f’ acc [xl,x2,...,xk,yl,y2,...,yk,...,zl,z2,...,zkj 
[def. off’] 

= foldl (\acc X -> f acc (toVector k x)) acc [xl,x2,...,xk,yl,y2,...,yk,...,zl,z2,...,zk] 
[def of toVector] 

= foldl (\acc X -> f acc [x]) acc fxl,x2,...,xk,yl,y2,...,yk,...,zl,z2,...,zkj 
]def of foldl] foldl h acc [x] = h acc x 

= foldl (\acc X -> h acc x) acc [xl,x2,...,xk,yl,y2,...,yk,...,zl,z2,...,zk] 

[rj conversion] 

= foldl h acc [xl,x2,...,xk,yl,y2,...,yk,...,zl,z2,...,zkj 
]def. of foldl] 

= (h (... (h (h (... (h ... (h (h (fh (h ... (h (h acc xl) x2) ... xk) yl) y2) 

... yk) ...) zl) z2) ...) zk) 

2 . foldl h acc s’ = foldl f acc s 
foldl f acc s 

]def. off] 

= foldl (foldl h) acc s 
[Lemma |2|+ def. of s’] 

= foldl h acc s ’ 

□ 
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6.7 About zip and unzip 

We use zip and unzip to change nested lists of tuples into tuples of nested lists. 

zip :: [a]<n> -> [b]<n> -> [(a,b)]<n> 
unzip :: [(a,b)]<n> -> ([a]<n>,[b]<n>) 

The same type transformation must be applied to both arguments, e.g. for R k 
[al<n>. In order to preserve the computation, it is quite clear that 

zip’ :: [[a]<k>]<n/k> -> [[b]<k>]<n/k> -> [[(a,b)]<k>]<n/k> 

can be implemented in terms of zip as 

zip’ xs’ ys’ = map (\(x,y) -> zip x y) (zip xs’ ys’) 
and similar for unzip. 

To simplify the discussion, we introduce a variant of zip, zipt, which takes a 
single tuple as argument, and a corresponding unzipt. 

zipt :: ([a]<n>,[b]<n>) -> [(a,b)]<n> 
zipt (xs,ys) = zip xs ys 

and 

unzipt :: [(a,b)]<n> -> ([a]<n>,[b]<n>) 
unzipt Itups = (map fst Itups, map snd Itups) 

then zipt’ becomes 

zipt’ :: ([a]<k><n/k>,[b]<k><n/k>) -> [(a,b)]<k><n/k> 
zipt’ tup = map zipt (zipt tup) 

and similar for unzipt. 

7 Conclusion 

The approach described allows to transform programs consisting of combinations 
of map, foldl and zip based on transformation of the types of the vectors on 
which the map or fold acts. 

We have shown that the the set V(a, n) oi vectors of type a and size n is closed 
under the proposed operations for transforming the vector types, S,M and R, 
with the corollary that every combination of the transformations is reversible. 

We have shown that, for programs consisting of opaque functions and the 
operations map, foldl and zip, the program transformations can be automatically 
derived from the type transformations. 

This mechanism allows to generate correct-by-construction variants of the 
programs. The purpose of this works is to allow automatic selection of the vari¬ 
ant most suitable for a given platform through optimisation against a platform 
cost model. 

This work is supported by the EPSRC through the TyTra project (EP/L00058X/1). 
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